A domain name system (DNS) allows Internet users to key a URL (Uniform Resource Locator) or domain name into the address line of their browser and access a corresponding server. An example of a URL is xe2x80x9chttp://www.foo.comxe2x80x9d, where http means Hypertext Transfer Protocol, www means World-Wide Web, foo is an example of a company name, .com means commercial (as opposed to .gov for government entities, .edu for education entities, .org for non-profit organizations, and so forth). An example of a host name in the URL is xe2x80x9cwww.foo.comxe2x80x9d. Progressing from left to right, the host name is structured from very specific to more general. Here, xe2x80x9cwww xe2x80x9d is the name of the server that handles Internet requests and is sometimes referred to as a third-level domain name, xe2x80x9cfoo xe2x80x9d is sometimes referred to as a second-level domain name, and xe2x80x9ccom xe2x80x9d is sometimes referred to as a top-level domain name. The URL may also take on a form: xe2x80x9chttp://www.foo.com/1.gifxe2x80x9d, where the last field, 1.gif, indicates a file name, but may also be a Web page, executable application, or other computer readable or executable file located at the URL that the user wishes to access.
When the user enters the URL into a browser, the browser makes a determination as to whether it knows a corresponding IP (Internet Protocol) address. For example, a corresponding IP address for foo.com might be 255.122.37.124. The browser knows the corresponding IP address if that host name has been visited recently and the address is still in a short-term host name address table in the browser. The user may also store the host name-to-IP address correspondence in the browser in some other manner, such as in a so-called xe2x80x9cfavorites xe2x80x9d log.
In a DNS-protocol network, such as the Internet, a common way for a browser to learn the IP address corresponding to the host name in a user-entered URL is for the browser to access a database in a DNS proxy, which is a form of a server that is tasked with resolving host names to IP addresses. DNS proxies are typically organized hierarchically on the Internet, where one DNS proxy may know a top-level domain address and lower level DNS proxies know subdomain addresses. Each DNS proxy has its own IP address on the Internet. The DNS proxy IP address is often unknown by the user since the Internet protocol enables the browser to access the DNS proxy in an automated manner, without requiring direction to the DNS proxy from the user.
A DNS proxy has limitations as to the number of host name-to-IP address mappings it can store. For this reason, the DNS proxy often accesses other network nodes that store the IP addresses for the host name, or portions thereof (e.g., the domain name and subdomain names). For example, if the DNS proxy were asked for the IP address of xe2x80x9cwww.foo.comxe2x80x9d, it may access an authoritative server that is responsible for storing the IP address of the foo.com domain name.
FIG. 1 provides a subset of the Internet 100 in which the above-described host name-to-IP address resolving process occurs. A user is operating a browser on the client machine 110. When the client 110 does not know an IP address of a host name residing on one of the servers 150, the client 110 issues a first message (step 1) to a DNS proxy 120.
Should the DNS proxy 120 not have the IP address for the URL in its address table, the DNS proxy issues a DNS request (step 2) to a central server 130 that is known to be authoritative for the host name in the URL. The central server 130 returns the corresponding IP address in an address record (step 3) to the DNS proxy 120. The DNS proxy 120 typically stores the corresponding IP address for a period of time and forwards it to the browser, which also stores the corresponding IP address. Using the corresponding IP address, the browser contacts the associated server (step 5) to access the user-specified URL. It should be understood that the URL may be located at multiple servers, and the DNS proxy 120 chooses the best server for the client, where choosing a best server is sometimes referred to as server selection.
Recently, content delivery systems have been added to the Internet to improve access time to information for clients. To access a content delivery system, a user merely types a URL into the browser, and the DNS system provides the corresponding IP address, as described above. Part of a content delivery system is a server selection subsystem. In server selection, a routed domain (a DNS domain and, implicitly, all its children) is redirected to one or more servers that can deliver the information requested. If there are problems with the way in which server selection is happening, it is possible that a user of the content delivery system could be directed to an inappropriate server, or that they are not being redirected to any servers at all. People noticing problems with the content delivery service contact a network operations center for the service provider to troubleshoot the problem.
A content delivery system may answer thousands of requests per second, providing redirection to a server that supports requested content. Although some diagnostic information may be logged on each such redirection, there is too much information logged to be able to understand it without some sort of filtering. Furthermore, the only identifying information available to the server selection system is the IP address of the network element requesting the redirection. This network element is typically the DNS proxy so the client is not visible to the server selection system. On the other hand, the DNS proxy is not visible to the end user during normal system operation. As a result, the network operator has a problem in starting the troubleshooting process. Although the redirecting system may be keeping logs of its actions with respect to each network element making requests, the end user calling with a problem typically does not know the address information of the relevant network element.
The present invention provides a means for the network operator, with the cooperation of the end user, to determine the address of the relevant network element. When a network operator is troubleshooting for a user who is having difficulty with a content delivery system or otherwise testing the system, it is important for the network operator to be able to determine the DNS proxy, or other network element used to obtain IP addresses, for that user. However, the user typically has no idea of the network address of their DNS proxy, and often does not know the IP address of his own network node (i.e., the client).
The present invention enables an operator to identify an address of a network element used by a particular client to obtain IP addresses. A user, operator, or other network node causes the client to send a test message to a test URL. The test URL includes a host name not known to the client or network element. Since neither the client nor the network element knows the corresponding IP address of the hostname in the test URL, the network element accesses a server known to be authoritative for the host name of the test URL. The server recognizes the test host name in a request from the network element and resolves the host name to an IP address. Also, the server registers the address of the network element making the request and optionally logs the network element DNS request. The test message may include a code in the host name of the test URL to identify the test message to the server. After registering the address of the network element making the request, the server hands back a test IP address for the client and records an IP address of the client when the client subsequently sends a message directly to the test IP address.
In an embodiment of the present invention, the user, network operator, or other network node causes the client to send the test message to a server, which, in turn, returns a redirect test message to redirect the client to the test URL. The server may parse the IP address of the client from the test message and incorporate the IP address of the client into the host name of the test URL, possibly with an encoded form of the IP address, which is decoded by the server. The client accesses the DNS proxy to get the IP address of the host name in the test URL, which accesses the authoritative server for the IP address of the host name in the test URL, since the host name in the test URL is designed to be unknown by the DNS proxy. By using the host namexe2x80x94of a host causing a problem for the user or to be identified for other reasonsxe2x80x94as part of the host name in the test URL, the resolving process for the host name in the test URL is expected to traverse the same path (i.e., access the same DNS proxy) as is reported to be giving the user trouble. In both embodiments, user unique test URLs may be generated to allow the operator to assist many users.